每個變更都有價格；沒被報價的變更不是免費，只是帳單寄去了別的地方。

會議尾聲的一句「順便」

昨天拆掉了「瀑布固定 Scope、敏捷固定 Time」這句口訣，結尾說：口訣背後真正該學的，是取捨。那取捨長什麼樣子？先看一個完全沒有取捨的現場。案例照例經過去識別化與合併改寫。

某個專案中期的客戶會議。議程走完，雙方心情都不錯，正要收筆電的時候，客戶窗口補了一句：

「對了，順便幫我加一個小功能。報表匯出的時候多帶一個部門欄位就好，很簡單吧？」

PM 幾乎沒有停頓：

「好，沒問題。」

會議在愉快的氣氛中結束。沒有人估、沒有人算、沒有人問那個欄位的資料從哪裡來。隔天早上，看板上多了一張 Ticket，標題就叫「報表加部門欄位」。

然後是接下來兩週的連鎖反應。

那個欄位的資料不在報表用的那張表裡，要跨到另一個模組去撈；那個模組的權限規則跟報表不一樣，部門資料誰能看得先對齊；改完之後，原本排好的測試從五天被壓成兩天，理由是「反正主要功能沒動」；另一個本來答應這一版要給的功能，悄悄滑到下一版，沒有正式通知任何人；兩位工程師連加了一週的班。

交付日當天，版本如期交付，客戶很滿意。PM 的進度回報寫著：

「本期如期完成，並額外納入客戶臨時新增之需求。」

從帳面上看，這個變更是免費的。

實際上，代價全都付了——只是沒有被記帳。

當時團隊怎麼理解那句「好」

事後去問，每個人都有一套說法，而且每句單獨聽都有道理。

PM 說：客戶關係要顧，會議氣氛那麼好，當場回「我回去估一下」多掃興；而且那真的是小功能，一個欄位而已。工程師說：東西是做得出來的，說做不到也不誠實。主管說：我們不是敏捷嗎？擁抱變化本來就應該的。至於多出來的工，大家 buffer 擠一擠總是有的。

這些說法合在一起，剛好繞開了一個問題：

這個變更的價格是多少？由誰支付？

注意，問題從來不是「該不該答應」。答應很可能是對的——客戶要的欄位也許真有價值。問題是「好」這個字說出口的時候，沒有人知道自己剛剛用什麼付了款。

沒有免費的 Change

標題那四個變數——需求（Scope）、時間（Time）、成本（Cost）、品質（Quality）——加上一個最常被忘記的 Risk，彼此是連動的。這不是管理學的修辭，是守恆律：

變更帶來的工作量不會憑空消失，只會轉移到某個變數上。

所以「這個變更做不做得到」是個不完整的問題。完整的問題是：這個變更，用什麼支付？選項一直都是同一張清單：

Scope    → 換掉哪一個？（要加這個，就把哪個拿出去）
Time     → 延多久？（交付日往後移幾天，並且說出口）
Cost     → 加多少？（加人加預算，含加人本身的磨合成本）
Quality  → 少測什麼？（哪些路徑這次不驗，而且大家知道）
Risk     → 賭什麼？（哪個環節這次不確認，賭它不出事）

這也不是瀑布或敏捷誰的問題，兩邊都有自己的收銀台。

瀑布的收銀台，Day 02 講過：變更走 Change，重新估算、重新承諾，Baseline 加上 Change 的總和才是新的承諾。敏捷的收銀台則長在排序裡：新需求進 Backlog，跟其他所有事情一起排優先序；排進下一輪的時候，因為一輪的容量有限，它必然擠掉同樣大小的別的東西。Day 04 說過，敏捷的承諾單位是一輪——正因為單位小，付款反而更頻繁、更誠實：每一輪都在明著問「這次做什麼、不做什麼」。

兩套方法形式差很多，但有一個共同點：

變更在進場之前，都要經過一個「決定用什麼支付」的動作。

而開場那個團隊做的事情是：跳過收銀台，直接把商品放進袋子。

所以那句「好，沒問題」的完整翻譯其實是：

「好。代價待定。事後由團隊內部自行吸收，不另行通知。」

有人報了價，只是報在心裡

這個變更後來為什麼消化得這麼順？因為報價這件事其實有人做了。

那兩位加班的工程師裡，資深的那位在動工前就把帳算完了：他知道部門欄位要跨模組去撈、知道權限規則會卡住、知道哪些測試「先跳過比較不會出事」、也知道被延後的那個功能客戶短期內不會追問。

換句話說，影響範圍、連動風險、付款方式的選擇——一份完整的變更報價，他全都做了。他選的付款方式是 Quality，加上自己的晚上。

只是這整筆帳沒有出現在任何地方。PM 不知道測試被砍掉了什麼，客戶不知道有個功能延後了，主管只看到「如期完成」。

於是組織學到的是：

「你看，小需求直接答應也不會怎樣。」

下一次會議尾聲的「順便」，只會更大聲、更頻繁。而每一次都能被吸收的原因都一樣：有人在腦子裡報價，在下班後付款。

這次到底誰在吸收代價？

老規矩。這次的帳單特別清楚，因為我們全程看著它被付掉：

Scope       □   一項都沒少，還多了一項
Time        □   交付日如期「達成」
Cost        □   帳面上沒有加任何人
Quality     ■   測試五天壓成兩天，砍了哪些只有一個人知道
Risk        □   沒有人重新評估過
人          ■   兩位工程師連加一週的班   ← 還是這格

跟 Day 02 一樣，Quality 跟人一起被勾。這不是巧合，是機制：

當付款方式沒有被選擇時，預設付款方式就是人；人吸收不完的部分，溢進 Quality。

而 Quality 的帳單會晚一點寄到——寄到的時候，抬頭通常寫著「線上事故」或「維護成本」。

如果沒有大神，應該留下什麼

答案不是「學會拒絕客戶」。報價不是拒絕。

報價的意思是：在「好」說出口之前，多一個動作——把價格攤開。攤開之後，客戶完全可以說「照做」，PM 也完全可以判斷「這個值得」。差別在於：這時付款方式是被選出來的，不是被默認的；付款的人知道自己在付款，而不是事後才發現薪水被扣。

還有一件事值得說破：最貴的變更往往不是大變更。大變更至少會被認真對待，有人開會、有人估算。真正貴的是那些「小到不值得報價」的變更——它們免檢入場，數量又多，而且每一件都預設由同一群人吸收。

所以今天要留下的東西很小，小到可以在會議室裡當場填完。

今日 Artifact｜最小變更報價單

下次任何人說「順便加一個」的時候，把這四行拿出來。填完再說「好」，也來得及：

□ 變更內容：對方想要的其實是＿＿＿＿
□ 實際範圍：需要動到＿＿＿＿（不只是表面上那顆按鈕）
□ 付款方式：本變更以＿＿＿＿支付
   （Scope 換掉＿＿／Time 延到＿＿／Cost 加＿＿／
     Quality 少測＿＿／Risk 賭＿＿，至少明選一項）
□ 同意人：這個付款方式由＿＿＿＿點頭

第三格填不出來的變更，不是免費，是還沒被計價。

而沒被計價的帳，最後都會寄到同一個地址。

今日一句

沒有免費的 Change；不選付款方式不代表不用付款，只代表預設由人代付。

不過，報價之前其實還有一個更早的問題。那句「順便幫我加一個」是客戶窗口說的——他說了算嗎？這個需求背後，提出的、決定的、使用的、驗收的，是同一個人嗎？

明天來談：工程師收到需求，不代表他收到的是聖旨。